Previous Page TOC Next Page



- 13 -
Exploiting Your Software


I played with a lot of titles for this chapter before I finally decided to use this one. It expresses the entire thought behind the way some people manage their systems today. In fact, it should express the way you use your system. Of course, exploiting your software could mean a lot of things, so I'll take a few minutes to define what I mean.

Exploiting every possible feature of some of today's software products would be impossible for the average user. The fact that some power users have a problem doing it really says something about software bloat. Take CorelDRAW! as an example. I recently installed the latest version of this product on my system. Even if I decided not to install all the fonts, I'd still have access to a drawing program, a presentation graphics program, and a desktop publisher—and that only scratches the surface. The folks at Corel thoughtfully provided me with three CD-ROMs full of valuable information, most of which I'll never use. Obviously, exploiting your software doesn't necessarily involve using every feature it has to offer.



Note: Don't get the idea that I'm bashing anyone by saying there's a certain level of software bloat in most packages today. The computing environment has become so complex and the tasks we perform so varied that you need to expect a certain level of bloat. Even if you don't use a particular feature, some users might feel that the package wasn't complete unless the vendor provided it. Combining the requests made by the majority of customers is the reason most vendors produce the bloated packages you see on the market today. A product feature I can't use to get my work finished might make all the difference in the world to someone else.

What do I mean by exploiting your software so it exercises every feature to its fullest potential? I use four basic criteria to measure my level of software exploitation. They're all interactive, so you'll find that changing one element affects all the other elements. For me, it's kind of a game to see just how well I can get all these elements to work together. A fully exploited piece of software will do the following:

Exploiting your software also means that you use the right tool for the task you're trying to accomplish. You can use a spreadsheet as a word processor (a lot of people do), but is that really exploiting your software, or is the software exploiting you? Of course, no one can afford to buy every application on the market. There are limitations to what you can realistically use. If an inexpensive tool will do the job, that's the one you should select. It's a matter of defining the parameters of the job. Just how much work do you need to do? If I need to dig a small hole, I get a spade. A really big hole requires a backhoe.

To summarize, then, exploiting your software means you get an application that's the right size and type for the job. You optimize its operation and environment. Then you sit back and watch the application do its job in the most efficient manner possible.

If this sounds impossible, read on. A lot of things seem impossible until you take the time to analyze the situation, break it into its component parts, and solve the small problems. Trying to take an entire project and solve it with one answer isn't going to do much, if anything, to make you efficient. Of course, you probably do all this with your current business. Most successful businesses take the time to get the most out of their employees and the resources they have available. Now what you need to do is apply these same principles to your computer.



Peter's Principle: Operating System Flexibility Is the Key

Windows 3.x was inflexible in some regards. Sometimes, a total system solution was impractical because you couldn't always work around its limitations. I have a lot of books and other resources sitting on my self that claim to provide the answer for Windows 3.x optimization or the inner secret that will unlock all its power. Even with all this help, I could seldom run more than three tasks at a time or fully exploit the software installed on my machine.

Using Windows NT has shown me that it still has bugs and other limitations. This product is still inflexible in some areas. In previous chapters, I even discussed some of the strange decisions Microsoft made when putting this operating system together. Even with all the little gotchas, though, Windows NT provides a level of flexibility that will enable you to circumvent the problem areas and (finally) use the system to its full potential. You can really exploit Windows NT. A fully optimized operating system does several things for you as the user. Besides all the obvious answers you'll probably recognize, such as improved stability, an optimized operating system allows you to fully exploit the software packages sitting on your shelf.

A flexible environment like Windows NT provides you with the space you need to maneuver that application into the best possible setup for use. Of course, with added flexibility comes some additional responsibility for the user. Microsoft still provides you with a default setup for your Windows installation. If you want to fully exploit your software, though, you need to fully exploit the operating system as well.




Tip: Exploiting your system means that you need to tune it, too. Have you ever seen a race-car driver who paid more attention to his paint job than his engine? Optimizing your applications doesn't really make sense until you spend a little time under the hood optimizing Windows. Read Chapter 3, "Performance Primer," if you need some ideas on how to do this.


Adding and Removing Applications


Have you seen the immense size of some applications today? I'm often appalled at how fast the applications I install can eat up a major piece of the 1GB drive on my machine. Most people don't have a drive this size, so sometimes they need to remove one or more applications they don't use much to make room for the applications they use often. If you ever tried to do this under Windows 3.x, you know how difficult it can be to actually perform this task. You'll be pleasantly surprised by a new Windows NT capability that enables you to install and remove your Windows NT applications with ease. This same capability works with Windows 95 applications as well.



Note: The Windows NT Install/Uninstall capability doesn't extend to older Windows NT-specific products—those designed for Versions 3.5 and older. It also won't work with any Windows 3.x application. To install and then later uninstall these products, you still need to use a third-party option. Unfortunately, this method also has a problem. The Windows NT utility ensures that the proper registry entries get made. You need to decide between using the capability to easily remove the application later and performing a little more work to get the application installed correctly or getting the best possible installation up front and doing a lot of work later to remove it. Using the correct installation utility will help you get rid of those old applications quickly.



Tip: Many of the newer applications on the market provide their own uninstall programs (in fact, it's a requirement for getting the Windows 95 logo). Chances are the custom uninstall program will work better than most third-party products because the vendor can hand tune its uninstall program. Unfortunately, this isn't always the case. I've had uninstall programs remove too many files or not enough. In some cases, they've even trashed the registry to the point where I had to reinstall some of my applications. When these native uninstall programs work, they work well. When they don't, watch out.

What's involved in removing an application after you've installed it? Every uninstall program should take the following five things into consideration. Uninstall programs handle each criteria to a different degree.



Tip: The section "Click Starts" in Chapter 5, "Startup Shortcuts," contains a procedure for viewing the contents of DLLs and other system files. You can use this procedure to view the files you suspect an application uses in order to decide whether or not to delete them. Making a list of the DL_ and DLL files on the distribution disk is also very helpful. Comparing this list to the contents of the SYSTEM directory will at least provide clues on what you can remove. Be careful, though, not to remove any "common" files your SYSTEM directory might contain. Reading the heading information for the DLL will also give you clues in this regard because common files are usually written by a compiler vendor and not the vendor of the application you're removing. (Unfortunately, this doesn't help much when it comes to Borland and Microsoft applications.)

As you can see, trying to remove a Windows application from your machine isn't the easy task that it was under DOS. A Windows application spreads files all over the place and makes entries in system files you might need, even if you do remove the application. (Multiple applications might need the same entry to run.) It's not too surprising, then, that Windows uninstall programs usually do a partial, not a complete, job of removing old programs from your system. Of course, a partial removal is better than nothing.



Tip: Windows won't let you remove a file that's in use. Even if you close an application, Windows might not unload all its associated DLLs right away. Whenever you want to remove an application from your drive, shut everything down, reboot, and perform the uninstall routine with all applications closed. This will ensure that the uninstall program can actually remove all the files it identifies as part of the application.


Standard Windows Applications


The latest version of Windows NT uses the same technique that Windows 95 does to ensure you can add and remove applications with ease. All this happens because the install program gives the operating system much more information about what it installs, and why, than previous versions of Windows. That's why you can uninstall only new Windows NT or Windows 95-specific applications with the new Install/Uninstall capability. Newer applications actually make registry entries that tell the operating system what to remove later. This also allows Windows NT to look for common files and perform other types of analysis. When you can finally upgrade every application on your machine to a newer Windows NT or Windows 95-specific version, the Install/Uninstall program should work perfectly—theoretically, at least.

Now that I have all the preliminaries out of the way, take a look at the future. Remember that I'm dealing with a less-than-optimal setup here because I don't have Windows 95 or Windows NT applications to replace all my current applications (and neither will you for the foreseeable future). Because of this problem, you might get slightly different results than I did. The following paragraphs tell you how to use the Install/Uninstall program.

  1. Open the Control Panel using the Start Menu or Explorer.

  2. Double-click Add/Remove Programs. You should see a dialog box like the one shown in Figure 13.1.

  3. Click Install. You'll see a dialog box similar to Figure 13.2. Notice that this dialog box tells you to place a floppy in one of the floppy drives or a CD-ROM in the CD-ROM drive. You don't have to do this. The Install/Uninstall program will let you search for applications on a hard drive. To use the automatic search features, however, you need to place a disk in the appropriate drive.

    Figure 13.1. The Install/Uninstall page lets you install any application, but it will uninstall only newer Windows NT or Windows 95 applications.

    Figure 13.2. Don't believe everything you read in this Install Program dialog box.

  4. Click Next. The Install Wizard will search the A drive, B drive, and CD-ROM drive for SETUP.EXE. If you're installing a program from the hard drive or if the setup program uses a different name, the wizard won't find it. You'll need to enter the value by hand or use the Browse dialog box.

  5. If the Install Wizard finds a setup program, it will type the name here for you. If not, you'll see a dialog box like the one shown in Figure 13.3. Type the name of the application you want to install or use the Browse dialog box to find it. To use the Browse dialog box, simply click the Browse button.

  6. As soon as you complete step 5, Windows NT launches the setup application. Follow the vendor instructions for installing it. You won't come back to the Install Wizard when you get done. You might want to open the Add/Remove Programs Properties dialog box again, though, to make sure that the application name appears in the list of products you can remove. Figure 13.4 shows a typical entry.

Figure 13.3. The Run Installation Program dialog box is the last time you see the Install Wizard.

Figure 13.4. The Install/Uninstall page contains an entry from an installed application.

Uninstalling an application is just as easy, if not easier, as installing it using the Install Wizard. The following procedure shows you the steps you'll follow in most cases. Remember that you also have the option of using the application's uninstall utility. Of course, the trade-off is that the application might not remove all the registry entries that Windows NT made when you installed it.

  1. Open the Control Panel using the Start Menu or Explorer.

  2. Double-click Add/Remove Programs. You should see a dialog box like the one shown in Figure 13.1.

  3. Select the application you want to uninstall and click Remove. The Install Wizard will ask if you want to remove the application, as shown in Figure 13.5. Notice that this dialog box also contains a list of everything it will remove. This list usually includes items such as .INI files. Some lists are more complete than others; it all depends on the application you want to remove.

  4. Click Yes. Just to make sure you really want to remove the application, Windows NT displays yet another screen asking if you're sure, as shown in Figure 13.6. This might seem a bit extreme until you consider how many people remove applications from their machines by mistake and regret it later.

    Figure 13.5. You always get to see which files Windows NT will remove before it actually does so.

    Figure 13.6. The Install Wizard always gives you a second chance to change your mind about uninstalling an application.

  5. Click Yes one last time. Windows NT will attempt to remove all the application components. If it's successful, it displays a success message. Otherwise, it displays the dialog box shown in Figure 13.7. You can use the contents of this dialog box to complete the uninstall process. In some cases, you won't actually have to do anything; just reboot the machine and reenter Windows to complete the process.

  6. Click OK to exit the Install Wizard.

Figure 13.7. The Install Wizard displays an error dialog box if it can't complete the uninstall.

Special Considerations for 16-Bit Applications


You'll find that your network probably has more 16-bit applications hanging around than you care to admit. I have a special application I use for printing labels; I could recompile that application in a 32-bit format, but most of you won't have that option. What do you do with those old applications? Once you see the ease with which your new Windows NT and Windows 95 applications install and remove, holding on to these hard-to-manage applications will take more than a little self control. Let's face it: The new applications you install will definitely make those old, but necessary, applications look completely out-of-date.

The best way to resolve the situation is to see if there is a new 32-bit version of the product that will work with Microsoft's Install/Uninstall Wizard. You're probably going to find that some applications just don't fall into that category, however; custom software is especially prone to this problem. Another way to resolve the problem is to find an update or patch that includes its own uninstall program. At least you could remove most or all of the program that way (the actual capabilities of these uninstall programs vary widely).

Despite your best efforts, some applications will sit on your machine and defy any reasonable attempt at removal. One of the ways that I've found to extend the useful life of those applications and still maintain the usability features provided by the new version of Windows NT is to use a program like WinDelete. This product is put out by IMSI and designed to work with those older 16-bit applications that lack an uninstall program.

What it does is create a snapshot of your system before and after you install an application. When you try to uninstall the program, WinDelete makes your system look like the snapshot before the installation. Of course, it takes into account any other changes in the meantime.

Does this system work perfectly? Not by a long shot. You can count on a product like WinDelete doing a nearly perfect job if the application you're trying to remove is the last one you installed. As the install gets older, your chance of removing it successfully diminishes. Trying to resolve all the changes that a 16-bit application makes to your system is no easy task. Some ambiguity (like which program actually owns a DLL or what changes a particular program makes to SYSTEM.INI during installation) will almost always result when products like WinDelete try to resolve differences between the snapshot of the system at the time of installation and its current state. WinDelete will help you out with uninstalling 16-bit applications, but it probably won't do the job perfectly.

How can you guard against problems? One way is to look through the vendor documentation to see if it provides a list of files that an application requires. Make a note of which files you installed. You can also make notes on the state of your machine before and after the install. Sometimes, a product like WinDelete misses a registry entry that you could easily remove later—as long as you know such an entry exists.

You'll also encounter a few problems when installing an older Windows application. A lot of those older applications rely on specific Windows behaviors, for example. One that comes to mind is screen saver products such as After Dark. I installed an older copy of this product on a Windows NT machine. The program didn't know what to do with a 32-bit environment. It was accustomed to the 16-bit environment where all the applications shared one message queue. The individual queues provided by Windows NT caused problems because After Dark could no longer monitor system activity correctly. What I got was a screen saver that would come on at the oddest moments. Shutting it off wasn't always successful. I finally removed it out of sheer frustration. Of course, I was thrilled when a new, Windows 95 version of the product came out that could handle the 32-bit environment.

You'll need to protect your installation by looking for odd entries in both WIN.INI and SYSTEM.INI. If an older 16-bit application relies on device drivers or DLLs to get the job done, it's almost certain that you'll have problems getting the application to work properly. Another problem application I had relied on a replaceable graphics driver to get the job done. You can just imagine the mess it created when it replaced the 32-bit driver used by Windows NT with its own 16-bit driver.

Special Considerations for DOS Applications


I haven't found a lot of gray areas in running DOS applications under Windows NT. Either it works or it doesn't; there doesn't seem to be a lot of middle ground. Unlike 16-bit Windows applications, a DOS application won't interfere with the operation of Windows itself when you install or remove it. In fact, removing a DOS application usually consists of a single step—removing the directory that holds the application. If you use a separate directory for your data, you shouldn't run into any problems if you decide to reinstall the application later.

You'll run into two basic problems when working with DOS applications. Every DOS application out there assumes that it's the only thing running on your machine. What happens if the install program decides to test your hardware? Windows NT isn't going to give up control of the machine. At the very least, you'll find that the program won't install at all. This is one of the reasons that multimedia DOS applications such as game programs won't install in many cases. They try to test the hardware and Windows NT stops them.

The other type of problem you'll encounter is when a DOS application needs to install a device driver or a TSR. The TSRs usually get installed during the installation process; you might not be able to get around any problems that they create. On the other hand, a device driver problem will probably show up when you try to run the application because it gets installed as part of the boot process. If Windows NT uses that device, it's certain that the DOS installation program is going to fail. The reason is simple: You can't run two device drivers for the same device. You have to give control of the device to either DOS or Windows.



Tip: Sometimes, a DOS program thinks that it needs a device driver—and usually it would if it were working under DOS. Windows NT provides the capabilities needed by the DOS program as part of the DOS environment, however. Try installing the program on another machine and then move the directory containing the program to your Windows NT drive. You might be surprised to find that the DOS application works without a hitch; the only problem was an install program that wouldn't work without installing a device driver.



Note: Windows NT uses a CONFIG.NT and AUTOEXEC.NT file in place of the normal CONFIG.SYS and AUTOEXEC.BAT for running a DOS application. What this means is that any changes a DOS application makes to these two files won't actually appear as part of the Windows NT until you move the changes. Make sure you check the section "Settings" later in this chapter for further details.

Don't get the idea that DOS applications that use device drivers or TSRs will work if Windows NT isn't using the device. I ran into one situation where I had to install a DOS application that captured data through an RS-422 port. Windows NT didn't use this device at all. The installation still failed because Windows NT detected a hardware access by the application. Windows NT will go overboard when it comes to any form of device access because that access could cause reliability or security problems.

I consider DOS applications okay under Windows 95 and marginal at best under Windows NT. When you install a DOS application, you're trying to do something that runs counter to Microsoft's philosophy for Windows NT. Don't be surprised if you fail in your attempt. The bottom line is that if you have a DOS application that you absolutely can't part with, you might want to look at Windows 95 instead of Windows NT as your operating system of choice.

Optimizing Windows Applications


Once you get a new application installed, you need to optimize it for your use. Notice I said "for your use." The difference between an optimized and an exploited application is simple: The optimized application might run fast, but the exploited application is more efficient. Windows applications provide a wealth of settings that enable you to tune the way they work. Not only do these tuning steps affect the application's speed and memory requirements, but they also affect the user interface. I'll look at both elements in the following sections because they're both important for fully exploiting your applications. Make sure you read the entire section before you start tuning your applications. Some elements are a trade-off: You need to select one over the other. I'll cover the most common choices, but you might need to make some decisions based on your application's specific setup.

Installation Options


Installing your new application is an important part of the tuning process. The decisions you make here affect the way you view the application in the future, as well as determine how the application performs. The following list should help you make some of the difficult decisions that will come up during installation.

The installation process that used to seem so straightforward is no longer so simple. You need to make some hard decisions before you embark on the actual installation process. The tips I just mentioned will help you make these generic decisions, but you'll find others more difficult to resolve. How do you balance workgroup and individual needs, for example? For some products, such as Lotus Notes, this is a major concern. Using products such as these requires the administrator to make some decisions for the benefit of the group as a whole. Some users will definitely view the decisions as arbitrary and overly confining. When working with workgroup-specific applications, you'll probably need to consider some additional problems.

Now that I've examined some of the things you need to consider when installing an application under Windows NT, the need to plan that installation becomes a lot clearer. Add to the installation problems the need to upgrade each user's machine and the cost of administrator time in doing so, and you begin to understand why some companies don't like software updates. Overall, a planned installation should provide you with a solid foundation on which to build your fully exploited application later.

Settings


Very few applications use the same settings. You'll find that applications of a particular kind (such as all word processors) might share a few of the same settings, but for the most part, you'll need to spend some time reading the user manual to figure them out. I won't discuss the actual process of changing your application's settings in this section; you'll need to read the vendor manuals later. I present some general principles you can use to make life easier. You can start looking at these areas for potential speed, memory, or efficiency gains.



Tip: Everyone's first inclination is to get into the application and complete this part of the setup immediately. That would probably be the worst mistake you could make. Software settings change as you learn how to use the application more efficiently. As your knowledge about the application increases, the feature that seemed important yesterday will appear almost foolish today. The settings I use for my applications are in an almost continuous state of flux. A little change here or a little tweak there can make a big difference in how well the application works for me. Take the time required to go through the tutorial first, and then make any setting changes you think will help. I usually keep NotePad handy to record any ideas I have while running the tutorial.

Changing your settings is largely a matter of personal preference. Even a small change can make a big difference in the way you use an application, however. You can do something as small as customize a Toolbar and reap a fairly large increase in efficiency, for example. Not using an application's auto-correct feature might enable you to run background tasks more efficiently. It's not the major changes you'll notice the most, but it's the little extras you add that make a difference in your computing environment. The following tips will help you get most of out of your applications:



Note: Windows 3.x provided a macro recorder that enabled you to record various Windows-related tasks and replay them later. The problem is that the macro recorder's implementation was flawed and people complained about it. The macro recorder had a lot of bugs that caused GPFs. It was also a little on the limited side as far as capabilities were concerned. Instead of fixing the problem, Microsoft decided to eliminate it. There is no macro recorder provided with the newer version of Windows NT.



Tip: There's an alternative way to use auto-correct. You can use it to substitute long phrases for short ones. Suppose that you have to type your company name a lot and the company name is Jackson Consolidated Freight Company. You can add an acronym like JCFC to your auto-correct dictionary. Every time you need to type your company name, you can shorten it to JCFC and your application will substitute the long name in its place.



Peter's Principle: My Settings Won't Work on Your Machine

We're all individuals. Nowhere is this more apparent than in the way we use software. I might think the way you do something is absurd; but if it works for you, it's probably the right way to go (at least until you learn better).

The world of applications does have some constants, and the wealth of available tip and technique books prove it. You can probably buy any number of tip and technique books that will help you get your application set up in a very short time with a minimum of effort. On the other hand, you need to make just as many, if not more, personal decisions. I usually include the Insert Annotation command for Word for Windows on my Toolbar, for example, because I use this feature a lot. I suggested the same thing to a colleague and he found it a waste of time because he used a different technique for making annotations.

I find that the same thing holds true for just about every type of user setting, but you might have to give up some autonomy in workgroup situations. I usually use three different user dictionaries: common, computer, and jargon. This enables me to keep some words separate so that they don't contaminate my general-purpose dictionary. In a workgroup situation, you might find that everyone needs to use the same dictionary to ensure consistent results for a project. The same thing holds true for other user settings such as templates and stylesheets. A group project usually requires the individual to defer to the group's needs to enforce a certain level of consistency.

The point is that you need to work with an application long enough to build a rapport with it. Once you figure out how you want to work with the application, you can start changing some of those personal settings to meet your specific requirements. In fact, you might find that some of your settings end up working for the group as well. Experimentation is a prime ingredient in finding the settings that work best for you.


Setting up an application is a continual process. Exploiting your software is often as much a matter of using the software in the best way you know how as it is a matter of optimizing memory and speed settings. Don't give up too much personal comfort for a perceived memory or speed benefit. You have to weigh the time a specific feature will save against what it will cost. That's what you do in other business decisions; evaluating your software is no different.

Running 16-Bit Windows Applications


Chapter 6, "An Architectural Overview," looked at how 16-bit applications run. That should clue you in to some of the problems you'll encounter running them. I have always felt that Windows NT does a better job in some regards than Windows 95. Under Windows 95, all 16-bit applications share one address space. This means they have to share the system resources required to display windows, icons, and graphic elements of all sorts. The same 16-bit application running under Windows NT executes in its own address space—making more memory available for graphics and other needed program resources. Windows NT has its own problems, though. I've actually seen some memory-intensive 16-bit applications grab more resources even though they didn't need them because they aren't running in a shared environment. There's always a trade-off involved in whatever environment you use. For the most part, I think you'll find the Windows 95/Windows NT trade-off for 16-bit applications works in favor of Windows NT.

Both operating environments do share one common problem. A 16-bit application in either environment faces problems such as cooperative multitasking, which I discussed earlier in the "Multithreading and Multitasking" section of Chapter 1, "A Decade Spent with Windows." That particular problem only gets worse under Windows NT because 32-bit applications run in their own session. You'll probably find that 16-bit applications get the short end of the deal when it comes to processor cycles.



Tip: Some older Windows applications display an invalid dynalink call error message when you try to run them. This means that they're incompatible with a new Windows NT version of a DLL. You have two choices. Upgrading the application is the best alternative because you'll replace that old product with something that will work better with Windows NT—a 32-bit version of what you used in the past. If upgrading isn't an option, reinstall the application, reboot Windows NT, and try it again. You have to reboot in order to reload the DLL into memory. Otherwise, you'll see the same error message because the Windows NT version is still in place. If you still get an invalid dynalink call message, there's some incompatibility between the application and a basic Windows NT system file. You absolutely must upgrade in this case because you can't replace those common files to meet the needs of one program. One or more Windows NT applications might cease to function if you do (including the operating system itself). Windows NT always maintains a copy of its system files in the SYSBCKUP folder under the main Windows folder. You can use this copy of the file to replace the old DLL if necessary.

The same types of optimization techniques you used under Windows 3.x will probably work under Windows NT as well. You'll still need to keep in mind the cooperative multitasking aspect of 16-bit applications when running certain types of applications in the background. You'll probably find it difficult to run your 16-bit database and your communications program at the same time at high speed, for example. The cooperative nature of these applications means that the database will probably take control of the system for that one second longer than the communication program can hold data in the buffer. The result is lost data. Windows NT is a lot better in this regard than Window 3.x was, but it still isn't perfect because the applications it runs aren't perfect.

Chapter 3 looked at many ways you can tune the Windows environment by getting rid of excess icons and the like. These same tips apply to applications for the most part. Make sure you spend some time reviewing that chapter for some additional hints.



Tip: Some 16-bit applications give you a choice between storing DLL files locally or in the Windows SYSTEM directory. Choose the local option to make it easier to remove the application later. This also reduces the chance that the application's setup routine will accidentally overwrite a Windows NT version of a file.

You should ignore a few of those old Windows 3.x optimization techniques when using Windows NT. The one I tell most people about is the use of virtual memory. If your system contained enough memory under Windows 3.x, you could get a performance boost by disabling virtual memory. Of course, this meant that you were effectively limited in the amount of system memory you could expect, but the performance gain was worth it. Don't disable virtual memory under Windows NT.

Using the Print Manager was something else a lot of people avoided when they needed to get their output fast. Windows NT uses a much improved form of Print Manager that you'll want to use for optimum performance. I'll stop short of saying that the output will arrive at the same speed, though. If you have a heavy system load when you start the print job, you'll definitely see a decrease in print speed. You gain increased system performance and regain control of your application faster as a result, however. It's another trade-off, but I think it's a good one in this case.

Running 32-Bit Windows Applications


I tested a lot of 32-bit applications and discovered a few interesting facts. Overall, a 32-bit application is larger and just a tad slower (when you view a single section of code) than its 16-bit counterpart. It's larger because you're using 32 bits for everything, even structures that might not require 32 bits. In addition, 32-bit code is typically larger than its 16-bit counterpart. Does this mean that 32-bit applications are memory hogs that you shouldn't use? Not by a long shot.

I want to explain the slower part of 32-bit application performance a little better. A 32-bit application starts out a tad slower than its 16-bit equivalent but ends up faster for a number of reasons. Most of these reasons have come from using a flat address space and the other architectural benefits of a 32-bit format. Yes, it takes more time to process 32-bit code than the equivalent sections of 16-bit code because the 32-bit code is larger. There's still a big speed benefit in the long run, however, because of the way a 32-bit application executes.

Running a 32-bit application has definite benefits in the way of speed. For one thing, it supports true multitasking. I found that background repagination in the 16-bit version of Word usually meant that I had to wait anyway until the application finished the task. Under the 32-bit version, Word spawns a task that really does run in the background. I seldom notice that anything is happening; the document just gets repaginated without my thinking about it. This is how multitasking should work from a user perspective.

Multitasking also helps you perform some tasks, such as printing, a lot faster than you could using a 16-bit application. For one thing, Windows can make better use of idle time with a 32-bit application. You'll notice that you regain control of the system faster. After a 32-bit application spawns a print task, it can return control of the computer immediately. It doesn't even need to slow you down as it checks on the status of the "background" print job like a 16-bit application does.

Warning: Every time a 32-bit application spawns a new task (called a thread), it uses some system resources. Some applications can create so many threads that your system begins to slow to a crawl and Windows runs out of resources. The second you run completely out of resources, the machine usually freezes. Although Microsoft did increase the size of some memory areas and move others to the 32-bit area, Windows NT still isn't perfect when it comes to managing 32-bit resources. The best thing to do is avoid the situation altogether. Don't try to run every feature that a 32-bit application can provide at one time. Limit the number of tasks you ask an application to perform in the background to a reasonable level. Finally, run the resource monitor from time to time just to see how you're doing on system resources. You might find you need to adjust some of your techniques to compensate for limitations in the Window NT design.

The big performance-tuning tip for Windows NT and 32-bit applications is to use as many automatic settings as possible. The more room you give Windows NT to compensate for changing system conditions, the better. Chapter 3 contained quite a few tips you could follow to optimize the environment. I discuss the need to monitor the swap file size to ensure that you don't end up wasting processor cycles in thrashing, for example. Once you optimize the environment for a 32-bit application, you have essentially optimized the application itself. All you need to do is check out the section called "Settings" earlier in this chapter to make the application as efficient as possible during use.

Optimizing DOS Applications


It'll be a long time before you see the demise of all DOS applications. It's true that very few commercial application vendors are updating their products anymore, but that isn't the total picture. The DOS scene offers more than just commercial applications.

One of the biggest areas where DOS will remain king for the foreseeable future is games. Why are games such a hot DOS item? The DOS environment gives the programmer access to more of the hardware and enables him to write a fast and visually stimulating program. Windows is notorious for grabbing too many system resources and running games at almost a snail's pace when compared to a DOS version of the same program. Microsoft is working on several strategies, including WinG, that will make Windows more attractive to game vendors, but they haven't accomplished that yet. I can usually find Windows versions of many games if I look hard enough, but the DOS versions are still selling like hotcakes, and I don't see this changing any time soon. Even if this were to change tomorrow, it's unlikely that users will give up their old games immediately. Some games have an amazing shelf life when you consider the technology they use. I still know people who like to play the original ZORK series, for example—a text-based DOS game with a great plot but no graphics at all.

Custom applications are another area where people are still using DOS, but it's for a different reason. A custom application can cost thousands of dollars. The consultant who writes the program has to charge that much because the chances of his selling more than a few hundred copies are slim at best. Because custom applications usually manipulate very sensitive company data that's hard to move to another application, people are going to think twice before attempting to move that data somewhere else. Fortunately, I see this particular class of DOS application coming to an end as Windows tools become easier and faster to use. A consultant can be a lot more productive now, so the cost is less for creating a new application in some cases.

Old habits die hard. Some people are accustomed to using DOS utility programs, so that's what they'll continue to use. These applications have perfectly acceptable substitutes in most cases—substitutes that are easier to use and that actually run faster—but some people just won't use them. This is the third group of people who will make at least some use of DOS under Windows NT.

I explore a variety of DOS options in the following sections. In most cases, I show you the best methods first and later add a few marginal methods you can use in a pinch. Of course, my advice is to move to a 32-bit Windows 95 or Windows NT application as soon as possible. DOS isn't dead, strictly speaking, but it does have one foot in the grave. Very few application vendors continue to support DOS. It won't be long before other vendors follow as well. You'll end up with a hard disk full of old applications that no one will support.

Understanding DOS Emulation


You use MS-DOS under Windows NT through the MS-DOS emulation mode. What actually happens is Windows makes a copy of the phantom DOS session stored in memory, spawns a new Virtual 86 session, and places the copy it made in the new session. What you see is either a windowed or full-screen DOS session (Microsoft has come up with new terminology recently that calls a DOS session the command-line prompt). All you need to do to open a DOS session is to select MS-DOS Prompt from the Start | Programs menu. You will also start a DOS session whenever you select a DOS application from either Explorer or the Start Menu.

As with everything else under Windows NT, right-clicking on the Command Prompt title bar produces a context menu. In this case, it contains three entries that are important to you as a user: Close, Edit, and Properties. The Close option allows you to close the DOS session without typing Exit and pressing Enter at the DOS prompt. The Edit option allows you to mark, copy, or paste text from the DOS screen to the ClipBoard. The Properties option displays the Properties dialog box shown in Figure 13.8.

Figure 13.8. The Command Prompt Properties dialog box allows you to reconfigure your DOS session on the fly.

As you can see, there are four pages to this dialog box. Each page works much like the PIF files you've used in the past (without the application settings, of course). I cover most of these settings in the "Settings" section of this chapter. The following list provides a quick rundown of the more important features you'll find on these four pages. (These are the features you'll normally use as part of an active DOS session versus application configuration.)

Now that we've gotten the Properties dialog box out of the way, let's talk about the Edit option on the Command Prompt context menu. As I mentioned previously, there are three main options to worry about: Mark, Copy, and Paste. A fourth option, Scroll, allows you to scroll the screen as needed during a capture. It only becomes active if the window buffer size is larger than the actual window. The following list covers the other three options in detail:

Figure 13.9. You can use the Mark button to copy part of the DOS screen to the Windows ClipBoard.

Once you get past the fancy new display, you'll see that DOS is unchanged. It doesn't really provide a lot more than you had in the past. One feature it does provide is long file name support. Use the DIR command if you want to see what I mean. Figure 13.10 shows the results of using it to display all the BMP files in the \WINNT\profiles\All Users\Start Menu\Programs directory.

Figure 13.10. DOS reacts differently when you use the DIR command under Windows NT.



Tip: You can also use long file names when typing commands. The only requirement is that you use quotation marks to enclose the long file name or directory, like this: DIR "Some Long Directory Name".

Besides adding long file name support, the DOS interface has a few new utility programs and changes to some old utilities. You no longer need to run a copy of QBasic to use Edit, for example. In addition, Edit now provides the capability to modify more than one file at once. I cover the specific changes in DOS utility support in the next section.

DOS Versus Windows NT Commands


Microsoft must have expected people to use the DOS prompt for a while longer, or they wouldn't have improved some of the utilities that come with Windows NT. I discussed one of those utilities earlier, so I won't describe it here again. The START utility—described in the section "Undocumented Parameters" in Chapter 5—is one new feature most people will really like. It enables you to start a Windows application from a full-screen DOS session. I really don't have room here to explore all the DOS commands, so I'm going to give you the highlights. The following list shows the changes that DOS (running under Windows NT) provides.



Note: The Windows NT approach to DOS has a number of differences from the approach used by Windows 95 because of some assumptions that Microsoft made. For instance, you'll find that Microsoft kept many of the DOS disk utilities in Windows 95—even to the point of providing batch file substitutes for them. The reason is simple: There's a good chance that someone using Windows 95 will want to maintain a dual-boot setup. They'll at least want to know why they can't use a particular command in MS-DOS mode (a feature that Windows NT doesn't support). You also need to remember that DOS is a much larger part of Windows 95 than it is Windows NT. Windows 95 is designed to be flexible—to enable you to use those older DOS applications. Windows NT assumes that you'll spend all of your time within Windows itself.

Although the Windows NT version of DOS provides some new features, you won't find a few of the old features. DOS doesn't include any of the following commands:

APPEND INTERLINK RAMDRIVE.SYS
ASSIGN INTERSVR RECOVER
BACKUP JOIN REPLACE
COMP MEMCARD RESTORE
DOSSHELL MEMMAKER ROMDRIVE.SYS
EDLIN MIRROR SHARE
EGA.SYS MSAV SMARTMON
FASTHELP MSBACKUP TREE
FASTOPEN POWER UNDELETE
GRAFTABL PRINT UNFORMAT
GRAPHICS PRINTER.SYS VSAFE
HELP
QBASIC

Microsoft's reason for removing the majority of these commands is that they aren't compatible with long file names. Other programs were removed because Windows NT supposedly makes them obsolete. I still would have liked to see Microsoft retain some of the commands. An enhanced version of QBASIC would have been nice for running those old BASIC utilities that I still have hanging around (one of which I use to calibrate my joystick). Obviously, there wasn't any reason to include some DOS utility programs such as MEMMAKER because Windows NT can't use them. Needless to say, some users will be unhappy about the absence of these commands and utilities.

Creating a DOS Session


You can create a DOS session using a variety of methods. Double-clicking a DOS application from inside Explorer creates a DOS session. The session ends as soon as you end the application.

Like previous versions of Windows, Windows NT includes a DOS prompt. All you need to do is click the MS-DOS Prompt option found in the Programs section of the Start Menu. You'll need to type exit and press Enter to end this session.

DOS Objects


As with any other object under Windows NT, right-clicking a DOS object displays a context menu like the one shown in Figure 13.11. You can cut, copy, and paste a DOS object like any other object that Windows NT supports. The Properties option will take you to the Properties dialog box, described in the next section. This is one major area where DOS applications are treated differently from Windows applications.

Figure 13.11. A DOS object's context menu looks like any other context menu under Windows NT.

Settings


A DOS application's Properties dialog box contains a lot more than the same dialog box for a Windows application does. In fact, if you were looking for the PIF (program information file) editor, here it is. The Properties dialog box shown in Figure 13.12 enables you to change every setting that the PIF editor provided and more. In fact, Windows NT provides several new features for DOS applications that make running them a snap.

Figure 13.12. The Properties dialog box replaces the old PIF editor that you used under Windows 3.x.

One of the things that differentiates Windows NT from Windows 95 is that the Properties dialog box contains several new entries. Windows 95 doesn't provide a security page, for example. In addition, not every DOS application uses all eight of the property pages that you see here. A few programs only need seven because they don't provide version information. A few others only use three because they don't allow you to configure things such as the amount of memory they use. The following sections describe each section of the Properties dialog box in detail.



Tip: Editing the Properties dialog box will not perform some mysterious trick with your DOS application. It saves the settings in a PIF file just like it did under Windows 3.x. In fact, Windows 3.x PIF files work just fine under Windows NT. You won't want to try to move the PIF files the other way, however. Windows NT adds a lot of information to the PIF file, making it incompatible with older versions of Windows.



Note: Windows NT makes use of some files that you won't find in either Windows 95 or Windows 3.x. The three files that will interest most users are CMD.EXE, AUTOEXEC.NT, and CONFIG.NT. Unlike other versions of Windows, the DOS command processor under Windows NT is CMD.EXE. Double-clicking this program will display a command prompt. This command processor looks at AUTOEXEC.NT instead of AUTOEXEC.BAT for anything that you need to load. Likewise, CONFIG.NT contains all of the configuration files that you used to place in CONFIG.SYS. It's important to remember these differences as you work with DOS applications under Windows NT because the changes will most likely affect how you set them up.


General

You'll find that every application under Windows NT provides a General page like the one shown in Figure 13.12. This page will tell you the full name, type, location, and size of the program. It also tells you whether the program is compressed.

The only user-configurable settings on this page are the file attributes. In most cases, the only attribute that you'll see checked is the Archive attribute. This tells you that the file hasn't been backed up since you installed it.

Version

Not every application provides the Version page shown in Figure 13.13. It tells you the vendor-specific information about the current program, something that comes in handy when you make a support call to the vendor. Notice the list box in the bottom half of the page. You can select the various items here to find out additional information about the program. Most applications provide a language entry to tell you what language the program uses, for example.

Figure 13.13. Windows NT provides a Version page that tells you who created a program along with other vital information.

Security

You can individually protect applications under Windows NT using the Security page shown in Figure 13.14. There are also options for auditing a file—determining when specific groups of people perform specific tasks with the file. Finally, there's a setting for determining who owns the file. I describe this page in detail in the section "Using the Security Page of the File or Folder Properties Dialog Box" in Chapter 23, "Security Issues."

Figure 13.14. The Security page enables you to monitor and control access to a particular file.

Program

The Program page (see Figure 13.15) enables you to change the way Windows executes the program. At the very top of the page, you'll see an icon and a field containing the application's name. This is the name you'll see in Explorer.

Figure 13.15. The Program page provides application-specific information.

The next three fields determine what application to run. The Cmd Line field contains the name of the application you want to run. It must end with an .EXE, .COM, or .BAT extension. In this case, I'm running a copy of the Disk Copy utility. The Working field tells Windows NT what directory to start the application from. In most cases, you'll start the application from either its home or its data directory. The choice depends on what kind of information the application requires to start. I'll run the Disk Copy utility from the current directory because it doesn't manage any data. The third field, Batch File, was new to Windows 95; Microsoft has added it as an enhancement to Windows NT as well. It enables you to designate a batch file that runs with the application. With the command processor, for example, you could include a batch file that would set up the path and prompt and load any TSRs you might need.

The Shortcut Key field enables you to assign a shortcut key to the program. Chapter 5 covered this, so I won't discuss it again here.

Use the Run field to determine how Windows NT runs the application. The three choices are Normal Window, Minimized, and Maximized. The first two choices affect both windowed and full-screen sessions. The third choice starts windowed sessions maximized.

It's usually a good idea to close the DOS session as soon as you get done. Checking the Close On Exit field does just that.

Clicking the Change Icon button displays the dialog box shown in Figure 13.16. It enables you to select the icon used to identify the application within Explorer and the Start Menu. Windows NT provides the same default choices as other versions of Windows. You can also choose from custom icon sets by clicking the Browse button.

Figure 13.16. This dialog box enables you to change the icon used to identify the DOS application.

The Windows NT button displays the dialog box shown in Figure 13.17. It enables you to change the AUTOEXEC and CONFIG files used to start the application. The default setting is to use AUTOEXEC.NT and CONFIG.NT, but you can choose any file you want.

Figure 13.17. The Windows NT PIF Settings dialog box enables you to choose the startup files for your application.



Tip: I kept a copy of my old DOS AUTOEXEC.BAT and CONFIG.SYS files handy for older applications that need a little extra help getting started. All you need to do is carefully prune from these files any programs or device drivers that aren't compatible with Windows NT before using them. I think you'll find a little editing is a lot faster than trying to recreate these files from scratch.

The Compatible Timer Hardware Emulation checkbox allows you to compensate for the needs of older programs. I've encountered more than a few of them that won't work on newer machines because they depend on timing loops. This checkbox changes that by emulating the timer hardware for the application.

Font

The Font page, shown in Figure 13.18, enables you to change the appearance of the fonts used to display data in a windowed DOS application. These settings don't affect a full-screen session.

Figure 13.18. The Font page allows you to control the way a DOS application is displayed in windowed mode.

This dialog box contains four main sections. The first section controls the type of fonts you get to see in the Font size list box. You'll usually want to use the fullest set of fonts available by selecting Both Font Types. The only time you might want to switch to one font type or another is if your display has problems displaying one type of font.

The second section contains the Font Size list box. It contains a list of the font sizes you have available for the DOS window. The numbers represent the number of pixels used for each character. A higher number of pixels makes the display more legible. A smaller number of pixels makes the window smaller.

The Window Preview section of this dialog box shows you how big the window will appear on the display. The Font Preview section shows you the size of the print. You should combine the output from these two displays to determine how large a font to use. It's important to reach a setting that balances the need to see what you're doing with the need to display the entire DOS box at once.

Memory

The Memory page, shown in Figure 13.19, is the most important page in the Properties dialog box from a tuning perspective. Notice that it has only five list boxes and two checkboxes, but the decisions you make here affect how the application runs. More importantly, they affect the way Windows runs. Chapter 3 discussed many of the effects this particular page has on Windows, so I won't go into them here.

Figure 13.19. The Memory page enables you to modify the way Windows allocates and manages memory for your DOS application.



Tip: In most cases, you'll want to keep all the list boxes set to Auto and both checkboxes unmarked on the Memory page. Windows usually performs better if you let it manage memory. The default settings might include checking the Protected checkbox, but unchecking this box will result in better application performance.

The first group of settings affects your conventional memory. The Total field enables you to select any value up to 640KB. You absolutely won't get more than 615KB of conventional memory, so don't try to set the conventional memory any higher than that. Windows usually allocates a 1,024-byte environment for your DOS application. This is enough to handle most situations. I usually set mine to 4,096 to provide space for all those environment strings required by real-mode compilers, however. The Protected checkbox is another diagnostic aid. Checking it tells Windows NT to monitor the application for memory protection errors. The only problem is that you'll suffer a performance loss when using it. If your application tends to corrupt memory, by all means check this box to keep your environment stable. Otherwise, consider leaving it unchecked for better performance.

The second group of settings contains a single list box that controls how much expanded memory Windows NT allocates for your application. If you leave it on Auto, MEM will report expanded memory up to the amount of memory your machine has installed. Windows NT will make only 16MB of it usable if you have more RAM than that installed. The only time you should change this setting is if the application grabs every bit of expanded memory it can find. Some older DOS applications get a little greedy, so you need to provide some controls for that greed.

The third group of settings controls the amount of extended memory available to your application. The default setting allocates the full amount of RAM installed on your system. This isn't an unlimited amount of memory, but it could be fairly high—much higher than the automatic expanded memory setting. As with the expanded memory setting, I usually change this setting from Auto to some specific number if the application gets greedy or if it has problems coping with the full amount of extended memory available on my machine. I usually leave the Uses HMA checkbox blank because I load DOS in the high memory area. If you don't use the HMA, however, you can always choose to load all or part of an application there by checking this box.

The final group of settings enables you to determine the amount of DPMI memory available to applications. Windows NT usually sets this to a value that reflects the current system conditions. There's little reason to change this setting from the default.

Screen

The Screen page, shown in Figure 13.20, enables you to configure the screen settings. The first group of settings, Usage, determines the screen mode and number of display lines. You should set the number of display lines here before you set the options on the Font page of this dialog box. Otherwise, a setting that worked well at 25 lines might not work at 50.

Figure 13.20. The Screen page allows you to adjust the size and type of display, as well as the method Windows uses to display it.

The second group of settings lets you change the window settings. It doesn't come into play if you use full-screen mode. I always set the Toolbar on. This is the Toolbar I described earlier in this section. It enables you to modify the font size and perform many other tasks with your application without opening the Properties dialog box. The second checkbox tells Windows NT to update the PIF to reflect any changes you made while using the Toolbar. Usually, the entries are good only for that session. I prefer that Windows remember my settings from session to session, so I check this box.

The third group of settings on this page affects your application's performance. I was a little surprised that this is the only section Microsoft chose to label as Performance, considering the number of other settings that affect the way your application will run. The first setting, Fast ROM Emulation, acts just like shadow RAM. It allows your application to use a RAM version of your display ROM. If an application had trouble with shadow RAM under DOS, it'll also have trouble with this setting. Otherwise, you will want to leave this checked to get maximum performance from your application.

The second setting in the Performance group helps Windows more than it helps the application. This setting allows Windows to retrieve some of the memory that the DOS application uses for graphics mode when it goes into character mode. This modicum of memory isn't much, but it could add up if you were running a lot of DOS sessions. As with so many other settings, giving Windows the flexibility it needs to fully control the memory on your system is usually a good idea. The only time you'd want to remove the checkmark from this setting is if your application spends all or most of its time in graphics mode.

Misc

The Misc (miscellaneous) page mainly provides settings that determine how Windows interacts with your application from a functional point of view. Figure 13.21 shows the settings you'll find here.

Figure 13.21. The Misc page enables you to control a variety of settings that don't fit in the other categories we explored.

The Allow Screen Saver setting doesn't really have much of an effect when you're using windowed applications. It determines whether Windows can interrupt a full-screen session to run a screen saver. Some full-screen applications really get confused if you allow the screen saver to operate. This is especially true of graphics applications and those that use RAM fonts. (A RAM font provides the checkbox and radio button controls that you see in some character-mode applications.)

The Mouse group contains two settings. The QuickEdit checkbox enables you to use a mouse within a DOS window, just like you would with any Windows application. This means you can select, copy, and paste with a lot less trouble than you could before. The Exclusive Mode checkbox gives a windowed application exclusive control over the mouse. The consequences of doing this on a permanent basis are pretty severe. This means that you can't use the mouse with your regular Windows applications as long as this application is active. It would probably be a better idea to run this application in a full-screen session if it has this much trouble sharing the mouse.

Some of the settings on this page can provide subtle performance control over your application. The Background and Idle Sensitivity controls fall into this category. Checking the Always suspend checkbox does more than suspend the application when it's in the background. It frees resources for Windows NT to use with other applications. If you're using a DOS application for data entry or some other task that requires continuous input, it pays to check this box and use those resources for other applications. The Idle Sensitivity setting also controls how Windows allocates resources. Usually, Windows tracks the amount of activity from an application. It if determines that the application is sitting there doing nothing while waiting for input from you, Windows NT will reduce its CPU resources. This is fine in most cases, but sometimes Windows doesn't give the application enough resources to complete the task it's performing. If this is the case, lowering the Idle Sensitivity setting will give the application the resources it needs at the expense of other applications that are running on the system at the time.

The Warn If Still Active checkbox in the Termination group displays a message if you try to terminate the DOS application window without ending the program first. Usually, you'll want to keep this checked to prevent potential data loss from a premature application termination.

Another performance enhancement, albeit a small one, is the Fast Pasting checkbox. You should usually keep this box checked so that Windows can use a high-speed method of pasting information into your DOS application. The only time you should change this is if data gets damaged during transition when you're using the fast paste mode.

The final group on our page controls the use of control key combinations under Windows NT. Checking a box in the Windows Shortcut Keys group enables Windows to use that key combination. Unchecking it allows the application to use the key combination. Obviously, you'll want to keep as many key combinations checked as possible. The only time you really need to change these settings is if the application needs them for some purpose and you can't change the application's settings.

On Your Own


Find a DLL for one of the smaller applications installed on your machine. Use the procedure in Chapter 5 for viewing the contents of files to determine which DLLs and other system files this application needs in order to work. Once you make up the list, see if other applications require the same files. You might be surprised by what you find. Windows NT reuses a lot of the same files.

Try running an ill-behaved DOS application such as a game under both Windows NT and Windows 95. What happens if the application causes system problems under Windows NT? Does Windows 95 respond in the same way? How does the application perform? Is it faster under Windows 95 or Windows NT? It pays to look at marginal applications to see what you can expect from an operating system. Try the same tests for an older 16-bit application.

Previous Page Page Top TOC Next Page